Authentication in a communication system

ABSTRACT

Methods and apparatus for providing Cellular Authentication Voice Encryption (CAVE) messages in an Extensible Authentication Protocol (EAP) format. The CAVE messages are sent via an EAP transport mechanism. The Mobile Station (MS) is able to use a common authentication mechanism for other technologies.

REFERENCE TO CO-PENDING APPLICATIONS FOR PATENT

[0001] The present Application for Patent is related to the followingco-pending Applications for Patent:

[0002] “Inter-working Function for a Communication System,” by RaymondHsu, filed concurrently herewith, having Attorney Docket No. 020503,assigned to the assignee hereof and hereby expressly incorporated byreference; and

[0003] “Key Generation in a Communication System,” by Raymond Hsu, filedconcurrently herewith, having Attorney Docket No. 020509, assigned tothe assignee hereof and hereby expressly incorporated by reference.

BACKGROUND

[0004] 1. Field

[0005] The present relates to authentication in a communication system,and more specifically to mechanisms for common authentication andsession key distribution using a common format, such as CellularAuthentication Voice Encryption (CAVE) for both voice and datacommunications.

[0006] 2. Background

[0007] As communication systems and infrastructures expand to provide avariety of voice and data services, the various protocols andauthentication procedures incur added complexity, additional use ofresources and time delays at set up. A common authentication mechanismfor cellular telephone systems is referred to as Cellular AuthenticationVoice Encryption or “CAVE.” Other mechanisms for authentication areimplemented in data systems, such as the mechanism referred-to asAuthentication and Key Agreement or “AKA.” When communication systemsare expanded to incorporate other services there may be multipleauthentication procedures used. There is therefore a need in the art toprovide a common format for authentication and set up.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008]FIG. 1 is an architectural illustration of the extension of theExtensible Authentication Protocol (EAP) to support a CellularAuthentication Voice Encryption (CAVE) algorithm.

[0009]FIG. 2 is a communication system.

[0010]FIG. 3 is a timing diagram of authentication processing in acommunication system.

[0011]FIG. 4A and FIG. 4B are fields in an EAP format.

[0012]FIG. 5A and FIG. 5B are examples of authentication processing in asystem wherein an EAP format supports the CAVE algorithm.

[0013]FIG. 6 is a flow diagram of authentication processing at anauthenticator.

[0014]FIG. 7 is a flow diagram of authentication processing at a mobilestation.

[0015]FIG. 8 is a wireless device supporting an extended EAP format thatsupports the CAVE algorithm.

DETAILED DESCRIPTION

[0016] The word “exemplary” is used herein to mean “serving as anexample, instance, or illustration.” Any embodiment described herein as“exemplary” is not necessarily to be construed as preferred oradvantageous over other embodiments.

[0017] An HDR subscriber station, referred to herein as an accessterminal (AT), may be mobile or stationary, and may communicate with oneor more HDR base stations, referred to herein as modem pool transceivers(MPTs). An access terminal transmits and receives data packets throughone or more modem pool transceivers to an HDR base station controller,referred to herein as a modem pool controller (MPC). Modem pooltransceivers and modem pool controllers are parts of a network called anaccess network. An access network transports data packets betweenmultiple access terminals. The access network may be further connectedto additional networks outside the access network, such as a corporateintranet or the Internet, and may transport data packets between eachaccess terminal and such outside networks. An access terminal that hasestablished an active traffic channel connection with one or more modempool transceivers is called an active access terminal, and is said to bein a traffic state. An access terminal that is in the process ofestablishing an active traffic channel connection with one or more modempool transceivers is said to be in a connection setup state. An accessterminal may be any data device that communicates through a wirelesschannel or through a wired channel, for example using fiber optic orcoaxial cables. An access terminal may further be any of a number oftypes of devices including but not limited to PC card, compact flash,external or internal modem, or wireless or wireline phone. Thecommunication link through which the access terminal sends signals tothe modem pool transceiver is called a reverse link. The communicationlink through which a modem pool transceiver sends signals to an accessterminal is called a forward link.

[0018] Authentication is the process of proving the identity of anindividual or application in a communication. Such identification allowsthe service provider to verify the entity as a valid user and also toverify the user for the specific services requested. Authentication andauthorization actually have very specific meanings, though the two namesare often used interchangeably, and in practice are often not clearlydistinguished.

[0019] Authentication is the process where a user establishes a right toan identity—in essence, the right to use a name. There are a largenumber of techniques that may be used to authenticate a user—passwords,biometric techniques, smart cards, certificates.

[0020] A name or identity has attributes associated with it. Attributesmay be bound closely to a name (for example, in a certificate payload)or they may be stored in a directory or other database under a keycorresponding to the name. Attributes may change over time.

[0021] Authorization is the process of determining whether an identity(plus a set of attributes associated with that identity) is permitted toperform some action, such as accessing a resource. Note that permissionto perform an action does not guarantee that the action can beperformed. Note that authentication and authorization decisions can bemade at different points, by different entities.

[0022] In a cellular network, the authentication feature is a networkcapability that allows cellular networks to validate the identity ofwireless device, thereby reducing unauthorized use of cellular networks.The process is transparent to subscribers. Customers are not required todo anything to authenticate the identity of their phones when they makea call.

[0023] Authentication typically involves a cryptographic scheme, whereinthe service provider and the user have some shared information and someprivate information. The shared information is typically referred to asa “shared secret.”

[0024] The A-Key

[0025] The authentication key (A-key) is a secret value that is uniqueto each individual cellular phone. It is registered with the cellularservice provider and stored in the phone and Authentication Center (AC).The A-key is programmed into the phone by the manufacturer. It can alsobe entered manually by the user, from the wireless device menu, or by aspecial terminal at the point of sale.

[0026] The wireless device and the AC must have the same A-key toproduce the same calculations. The primary function of the A-key is tobe used as a parameter to calculate the shared secret data (SSD).

[0027] The Shared Secret Data (SSD)

[0028] The SSD is used as an input for authentication calculations inthe wireless device and the AC, and is stored in both places. Unlike theA-key, the SSD may be modified over the network. The AC and the wirelessdevice share three elements that go into the calculation of the SSD: 1)the Electronic Serial Number (ESN); 2) the Authentication Key (A-Key);and 3) a RANDom number for Shared Secret Data calculation (RANDSSD).

[0029] The ESN and RANDSSD are transmitted over the network and over theair interface. The SSD is updated when a device makes its first systemaccess, and periodically thereafter. When the SSD is calculated, theresult is two separate values, SSD-A and SSD-B. SSD-A is used forauthentication. SSD-B is used for encryption and voice privacy.

[0030] Depending on the capabilities of the serving system, SSD may beshared or not shared between the AC and serving Mobile Switching Center(MSC). If secret data is shared, it means the AC will send it to theserving MSC and the serving MSC must be capable of executing CAVE. If itis not shared, the AC will keep the data and perform authentication.

[0031] The type of sharing affects how an authentication challenge isconducted. An authentication challenge is a message sent to challengethe identify of the wireless device. Basically, the authenticationchallenge sends some information, typically random number data, for theuser to process. The user then processes the information and sends aresponse. The response is analyzed for verification of the user. Withshared secret data, a challenge is handled at the serving MSC. Withnon-shared secret data, a challenge is handled by the AC. By sharingsecret data, the system may minimize the amount of traffic sent andallow challenges to happen more quickly at the serving switch.

[0032] Authentication Procedures

[0033] In a given system, a Home Location Register (HLR) controls theauthentication process by acting as intermediary between the MSC and AC.The serving MSC is set up to support authentication with the mobile'sHLR and vice versa.

[0034] The device initiates the process by notifying the serving MSC ifit is capable of authentication, by setting an authorization field inthe overhead message train. In response, the serving MSC starts theregistration/authentication process with an Authentication Request.

[0035] By sending the Authentication Request, the serving MSC tells theHLR/AC whether it is capable of doing CAVE calculations. The AC controlswhich of the serving MSC's as well as device capabilities will be usedout of those available. When the serving MSC does not have CAVEcapability, the SSD cannot be shared between the AC and MSC andtherefore all authentication processes are performed in the AC.

[0036] The purpose of the Authentication Request (AUTHREQ) is toauthenticate the phone and request SSD. The AUTHREQ contains twoparameters for authentication, the AUTHR and RAND parameters. When theAC gets the AUTHREQ, it uses the RAND and the last known SSD tocalculate AUTHR. If it matches the AUTHR sent in the AUTHREQ thenauthentication is successful. The return result to the AUTHREQ willcontain the SSD if it can be shared.

[0037] The Challenge

[0038] The Authentication process consists of a challenge and responsedialog. If SSD is shared, the dialog runs between the MSC and thedevice. If SSD is not shared, the dialog runs between the HLR/AC and thedevice. Depending on the switch type, the MSC may be capable of either aUnique Challenge, a Global Challenge, or both. Some MSCs are currentlynot capable of global challenge. The Unique Challenge is a challengethat occurs during call attempts only, because it uses the voicechannel. Unique challenge presents an authentication to a single deviceduring call origination and call delivery. The Global Challenge is achallenge that occurs during registration, call origination, and calldelivery. The Global challenge presents an authentication challenge toall MSs that are using a particular radio control channel. It is calledglobal challenge because it is broadcast on the radio control channel,and the challenge is used by all phones accessing that control channel.

[0039] During a challenge, the device responds to a random numberprovided by the MSC or AC. The device uses the random number and sharedsecret data stored in the device to calculate a response to the MSC. TheMSC also uses the random number and shared secret data to calculate whatthe response from the device should be. These calculations are donethrough the CAVE algorithm. If the responses are not the same, serviceis denied. The challenge process does not increase the amount of time ittakes to connect the call. In fact, the call may proceed in some cases,only to be torn down when authentication fails.

[0040] As stated hereinabove, the CAVE algorithm is commonly used forcellular communications and therefore, is well used and distributed.Alternate algorithms for authentication are also used. Specifically indata communications a variety of algorithms exist of varying complexityand application. To coordinate these mechanisms, the ExtensibleAuthentication Protocol (EAP) has been developed as a general protocolframework that supports multiple authentication and key distributionmechanisms. The EAP is described in “PPP Extensible AuthenticationProtocol (EAP)” by L. Blunk et al, RFC 2284, published March 1998.

[0041] One such mechanism supported by the EAP as defined in “EAP AKAAuthentication” by J. Arkko et al., currently an Internet draft,published February 2002, is the AKA algorithm. There is a need thereforeto extend EAP to include the cellular algorithm CAVE. This is desirableto provide back compatibility for new systems and networks.

[0042] EAP

[0043] The Extensible Authentication Protocol (EAP) is a generalprotocol for authentication which supports multiple authenticationmechanisms. EAP does not select a specific authentication mechanismduring link set up and control, but rather postpones this until theauthentication procedure begins. This allows the authenticator torequest more information before determining the specific authenticationmechanism. The authenticator is defined as the end of the link requiringthe authentication. The authenticator specifies the authenticationprotocol to be used in the during link establishment.

[0044]FIG. 4A illustrates some of the fields assigned according to EAP.As illustrated, the EAP 300 defines a first field CODE field 302 whichidentifies the type of message. The IDENTIFIER field 304 allows forcorrelated responses, wherein the challenge will have an identifierassociated with it that is also used by the response to the challenge.The LENGTH field 306 gives the length of the EAP request packet. TheTYPE field 308 identifies the type of EAP message that is contained inthe PAYLOAD field 310. For example, for AKA authentication, the TYPEfield 308 will identify the information as AKA information, and thePAYLOAD field 310 will include an AKA challenge, response, etc.

[0045] CAVE Application of EAP

[0046] According to one embodiment of the present invention, the EAP isextended to support CAVE authentication. As illustrated in FIG. 1, anarchitecture for implementing CAVE using EAP allows the CAVEauthentication procedures to be applied directly to voice type systemsand any other system that supports CAVE. Each block represents analgorithm or messaging type used according to the architecture of thepresent embodiment. CAVE 102 applies to both the voice network and thedata network. For voice communications, CAVE 102 uses a signalingmessage 120 to facilitate authentication. For data communications, CAVE102 uses the EAP 104 to facilitate authentication. EAP 104 may beimplemented with PPP framing format 106, Internet Protocol (IP) packetformat 108, or consistent with a Remote Authentication Dial-In UserService (RADIUS) message format 110. RADIUS is an Internet userauthentication described in RFC 2138, “Remote Authentication Dial InUser Service (RADIUS)” by C. Rigney et al., published April 1997.

[0047]FIG. 2 illustrates a communication system 200 employing thearchitecture of one embodiment. The Mobile Station (MS) 202 is incommunication with an authenticator 204. The authenticator initiatesauthentication of the MS 202 when the MS attempts to access dataservices 208 (outside of the network 210) or data services 206 (withinthe network 210). Note that system 200 may include any number ofservices both in and out of the network 210. The authenticator 204implements the CAVE algorithm using EAP. The call processing isillustrated in FIG. 3.

[0048] As illustrated in FIG. 3, the authenticator 204 initiates theauthentication process with MS 202. The authenticator 204 first sends arequest for identification to MS 202 by sending an EAP-Request/Identitymessage to the MS 202. In response, the MS sends anEAP-Response/Identity message containing the International MobileSubscriber Identity (IMSI) of the MS 202, or containing an alias nameassociated with the MS 202. Since the EAP-Response/Identity message isin clear text, i.e., not yet encrypted data, it is vulnerable toeavesdropping over the air during transmission. Since IMSI is consideredto be sensitive information to the MS 202, the MS 202 may desire toprovide identity using a known alias name. In this case, theauthenticator 204 maps the MS 202 alias name to the MS 202 IMSI. Anexample of an alias name is user@realm (e.g., joe@abc.com).

[0049] Based on the MS 202 IMSI, the authenticator 204 determineswhether the MS 202 is using CAVE for access authentication. To make suchdetermination, the authenticator 204 sends an“EAP-Request/CAVE-Challenge” message to the MS. The message is sent asan EAP Request message containing a CAVE challenge in the payload. Theformat for the request is illustrated in FIG. 4B and discussedhereinbelow. The EAP-Request/CAVE-Challenge message contains achallenge, which is a random number generated by the authenticator 204.

[0050] The MS 202 then computes an authentication response byapplying: 1) secret data; 2) the IMSI of MS 202; and 3) the challengereceived, as input to the CAVE algorithm. The result is then provided asan “EAP-Response/CAVE-Challenge” message or response to theauthenticator 204. The MS 202 sends the EAP-Response/CAVE-Challengemessage to the authenticator 204, wherein the message contains theauthentication response. The message does not necessarily contain the MS202 identify (e.g., IMSI or alias name) and/or the challenge, becausethe message will use the same message identifier as theEAP-Request/CAVE-Challenge message sent by the authenticator 204originally. Via the message identifier, the authenticator 204 mayassociate the MS 202 authentication response with the MS 202 identityand the challenge.

[0051] The authenticator 204 then verifies the MS 202 authenticationresponse by comparing it with the expected response. The authenticator204 may or may not know the MS 202 shared secret. If the authenticator204 knows, or has knowledge of, the shared secret, the authenticator 204computes an expected response by using the MS's shared secret, MS'sIMSI, and the challenge as input to the CAVE algorithm. If theauthenticator 204 does not have the secret, it obtains the expectedresponse from the entity that has the MS 202 shared secret.

[0052] If the MS 202 authentication response is the same as the expectedresponse, the MS 202 passes the authentication, and the authenticator204 sends the “EAP-Success” message, so indicating, to the MS 202. Ifthe MS 202 fails the authentication, the authenticator 204 sends an“EAP-Failure” message (not shown), indicating the authenticator 204 wasunable to authenticate the MS 202 for the desired access, to the MS 202.

[0053]FIG. 4B illustrates the extension of the EAP for application ofCAVE authentication procedures. As illustrated, the TYPE field 308 isextended to TYPE filed 312 which includes a CAVE option. The associatedPAYLOAD field 314 is then adapted to include a CAVE message, e.g., CAVEchallenge or CAVE response. In this way, the EAP may be used with CAVEauthentication procedures. Specifically, the EAP will be the transportmechanism for the negotiations involved in the CAVE authentication. CAVEspecifies the messages and the order of messages required forauthentication. CAVE further specifies the authentication proceduresperformed at the MS 202 and the authenticator 204, as well as theinformation and variables needed for such authentication. The EAPspecifies how the information and variables, messages, etc. to implementCAVE authentication are communicated between the MS 202 and theauthenticator 204. Once the CAVE option is specified in the EAP message,the content of the CAVE message(s) is invisible to the EAP procedures.

[0054]FIGS. 5A and 5B illustrate various scenarios for implementation ofCAVE with EAP. In FIG. 5A, the EAP request message from theauthenticator 204 is made as a CAVE challenge. In other words, the TYPEfield 312 identifies the request as a CAVE message, and the PAYLOADfield 314 contains the CAVE message, which in this case is a CAVEchallenge. The MS 202 receives the CAVE challenge via the EAP requestmessage, processes the received information contained in the PAYLOADfield 314 according to the CAVE procedures, and provides the result as aCAVE response back to the authenticator 204 via an EAP response message.

[0055] In FIG. 5B, the EAP request message from the authenticator 204 ismade according to another authentication procedure referred to as the“MD5-Challenge,” which is also known as the Challenge HandshakeAuthentication Protocol (CHAP). The MS 202 receives the EAP requestmessage but does not support the MD5-Challenge procedures and thereforereplies with a Negative Acknowledge message as an EAP response message.Note that the messages sent between the authenticator 204 and the MS 202are EAP messages. The authenticator 204 receives the NAK via the EAPresponse message and attempts to authenticate using another type ofalgorithm. The authenticator 204 may try any number of algorithm typesas supported by the EAP format. In this case, the authenticator 204sends a CAVE challenge in an EAP request message. The MS 202 receivesthe information, calculates a response, and responds with a CAVEresponse in an EAP response message. In this way, the authenticator 204is able to determine the capability of the MS 202 and respondaccordingly.

[0056]FIG. 6 is a flow diagram of authentication procedures according toone embodiment at the authenticator 204. The process 400 begins when theauthenticator 204 receives a request for a given service at step 402.The request for service may for data services, voice services, or acombination thereof. The authenticator 204 then determines if thecommunication is voice or data at decision diamond 404. Note that acombination type service, such as Voice over IP (VOIP) is typicallytreated as a data communication. For data services, processing continuesto step 406 to send an EAP request for identification of the MS 202. Theauthenticator 204 receives a response from the MS 202 at step 408. Inresponse to the MS 202 identification, the authenticator 204 sends aGAVE challenge via an EAP request message at step 410.

[0057] The authenticator 204 then determines the status of theauthentication procedure at decision diamond 416. If the authenticationof MS 202 passed, the authenticator 204 authorizes the service at step418. If the authentication of MS 202 fails, then the authenticator 204notifies the MS 202 of a failure to authenticate at step 420.

[0058] For voice communications, from decision diamond 404 theauthenticator 204 sends a CAVE challenge as a signaling message at step412. The authenticator 204 receives a CAVE response at step 414. Theprocessing then continues to decision diamond 416 to determine thestatus of the authentication.

[0059]FIG. 7 is a flow diagram of an authentication procedure at the MS202. The MS 202 sends a request for data services at step 502. Inresponse thereto, the MS 202 receives a request for identification in anEAP request message at 504. The MS 202 then sends identificationinformation in an EAP response message at step 506. A challenge isreceived via an EAP request message at step 508. At decision diamond510, the MS 202 determines the format of the challenge. If the format isaccording to the CAVE algorithm, then processing continues to step 512;else processing continues to step 518 to send a NAK message via an EAPresponse. From step 518 processing returns to step 508 to await anotherchallenge. If the challenge was a CAVE challenge, then processing atstep 512 computes a response as described hereinabove and consistentwith CAVE procedures. The MS 202 sends the response as an EAP responsemessage at step 514. The MS then receives confirmation of theauthentication at step 516 and the authentication procedure is complete.

[0060] A wireless device, such as MS 202, is illustrated in FIG. 8. Thedevice 600 includes receive circuitry 602 and transmit circuitry 604 forreceiving transmissions and sending transmissions, respectively. Thereceive circuitry 602 and the transmit circuitry 604 are both coupled toa communication bus 612. The device 600 also includes a CentralProcessing Unit (CPU) 606 for controlling operations within the device600. The CPU 606 is responsive to computer-readable instructions storedin memory storage devices within the device 600. Two such storagedevices are illustrated as storing the CAVE procedure 608 and the EAPprocedure 610. Note that alternate embodiments may implement theprocedure in hardware, software, firmware, or a combination thereof. TheCPU 606 is then responsive to authentication processing instructionsfrom the CAVE procedure 608. The CPU 606 places the CAVE procedure 608messages into an EAP format in response to EAP procedure 610. The CPU606 further processes received EAP messages to extract the CAVE messagestherefrom.

[0061] Those of skill in the art would understand that information andsignals may be represented using any of a variety of differenttechnologies and techniques. For example, data, instructions, commands,information, signals, bits, symbols, and chips that may be referencedthroughout the above description may be represented by voltages,currents, electromagnetic waves, magnetic fields or particles, opticalfields or particles, or any combination thereof.

[0062] Those of skill would further appreciate that the variousillustrative logical blocks, modules, circuits, and algorithm stepsdescribed in connection with the embodiments disclosed herein may beimplemented as electronic hardware, computer software, or combinationsof both. To clearly illustrate this interchangeability of hardware andsoftware, various illustrative components, blocks, modules, circuits,and steps have been described above generally in terms of theirfunctionality. Whether such functionality is implemented as hardware orsoftware depends upon the particular application and design constraintsimposed on the overall system. Skilled artisans may implement thedescribed functionality in varying ways for each particular application,but such implementation decisions should not be interpreted as causing adeparture from the scope of the present invention.

[0063] The various illustrative logical blocks, modules, and circuitsdescribed in connection with the embodiments disclosed herein may beimplemented or performed with a general purpose processor, a digitalsignal processor (DSP), an application specific integrated circuit(ASIC), a field programmable gate array (FPGA) or other programmablelogic device, discrete gate or transistor logic, discrete hardwarecomponents, or any combination thereof designed to perform the functionsdescribed herein. A general purpose processor may be a microprocessor,but in the alternative, the processor may be any conventional processor,controller, microcontroller, or state machine. A processor may also beimplemented as a combination of computing devices, e.g., a combinationof a DSP and a microprocessor, a plurality of microprocessors, one ormore microprocessors in conjunction with a DSP core, or any other suchconfiguration.

[0064] The steps of a method or algorithm described in connection withthe embodiments disclosed herein may be embodied directly in hardware,in a software module executed by a processor, or in a combination of thetwo. A software module may reside in RAM memory, flash memory, ROMmemory, EPROM memory, EEPROM memory, registers, hard disk, a removabledisk, a CD-ROM, or any other form of storage medium known in the art. Anexemplary storage medium is coupled to the processor such the processorcan read information from, and write information to, the storage medium.In the alternative, the storage medium may be integral to the processor.The processor and the storage medium may reside in an ASIC. The ASIC mayreside in a user terminal. In the alternative, the processor and thestorage medium may reside as discrete components in a user terminal.

[0065] The previous description of the disclosed embodiments is providedto enable any person skilled in the art to make or use the presentinvention. Various modifications to these embodiments will be readilyapparent to those skilled in the art, and the generic principles definedherein may be applied to other embodiments without departing from thespirit or scope of the invention. Thus, the present invention is notintended to be limited to the embodiments shown herein but is to beaccorded the widest scope consistent with the principles and novelfeatures disclosed herein.

What is claimed is:
 1. A remote station apparatus comprising: aprocessing unit; a memory storage unit coupled to the processing unit,the memory storage unit storing authentication procedure instructions;and a second memory storage unit coupled to the processing unit, thesecond memory storage unit storing a transport format instructions fortransmitting the authentication procedure instructions.
 2. A method forauthenticating a communication, comprising: requesting a data service;determining a voice communication authentication protocol; and using thevoice communication authentication protocol to authenticate the dataservice.
 3. The method as in claim 2, wherein using comprises: storingmessages of the voice authentication protocol in a transport message;and transmitting the transport messages.
 4. The method as in claim 2,wherein the authentication protocol is a Cellular Authentication VoiceEncryption (CAVE) algorithm.
 5. The method as in claim 4, wherein thetransport message is an Extensible Authentication Protocol (EAP)message.
 6. The method as in claim 2, wherein the transport message isan Extensible Authentication Protocol) message.
 7. An ExtensibleAuthentication Protocol (EAP) message, comprising: a first field foridentifying the type of a message to transmit, the first fieldsupporting a plurality of types, wherein one of the plurality of typesin a Cellular Authentication Voice Encryption (CAVE) message; and asecond field for the message.
 8. A method, comprising: sending CellularAuthentication Voice Encryption (CAVE) challenge message as anExtensible Authentication Protocol (EAP) message; receiving a CAVEresponse message as an EAP response message, the CAVE response messagein response to the the CAVE challenge message; and determiningauthentication of a service based on the CAVE response message.
 9. Anapparatus for authenticating a communication, comprising: means forrequesting a data service; means for determining a voice communicationauthentication protocol; and means for using the voice communicationauthentication protocol to authenticate the data service.